|
|
Subscribe / Log in / New account

Speed and bandwidth improvements with Firefox Tracking Protection

By Nathan Willis
May 28, 2015

Browser safeguards that block web-tracking technology are usually touted for the privacy gains that they offer to users. But recent research from Mozilla reveals yet another benefit: substantially increased web-browsing performance. The researchers studied the effects of Firefox's built-in Tracking Protection feature, and measured a roughly 40% reduction in load times and data usage—on certain sites—as a result.

The Tracking Protection feature was introduced in Firefox 35. It relies on a human-curated blacklist of untrusted domains; when the feature is enabled, Firefox intercepts and removes all outgoing HTTP requests to blacklisted domains. The human-curated list lets Firefox block not just simple cookies, but more sophisticated measures as well—while preventing the site-breakage that can accompany a broad content-blocking policy.

The ill effects of web trackers are well known, of course. In addition to the obvious (disclosing large amounts of personal data to advertisers), there are also law-enforcement programs, government and corporate espionage, and even healthcare companies that may be interested in observing one's habits. No doubt there are new buyers for such tracking information every day.

As of now, Firefox Tracking Protection must be enabled by the user manually changing the privacy.trackingprotection.enabled setting to true in Firefox's about:config page. It is a distinct feature from Firefox's Do Not Track user preference (which sends a header that, regrettably, many sites simply choose to ignore). The closest comparison is probably to the Electronic Frontier Foundation (EFF) add-on Privacy Badger—though Privacy Badger uses heuristics, rather than a blacklist, to decide which trackers to block.

The Tracking Protection feature grew out of Mozilla's Polaris initiative, a collaboration with the EFF and Stanford University's Center for Internet and Society (CIS). Back in 2013, CIS and Mozilla had investigated using a public Cookie Clearinghouse as the basis for its blacklist; the current Firefox Tracking Protection feature uses the Disconnect blacklist as its base instead.

On May 21, the results of Tracking Protection research by Georgios Kontaxis from Columbia University and Monica Chew (until recently, of Mozilla) were announced. Their paper [PDF] was presented at the IEEE's Web 2.0 Security and Privacy workshop, where it won the "best paper" award.

The paper describes how Tracking Protection works in more detail. The blacklist contains around 1500 domains and is updated every 45 minutes in order to minimize interruptions caused by false positives. The list is not exposed in the user interface; it is transmitted and amended in hashed form using Mozilla's implementation of the Safe Browsing API to protect again interception. To test its performance, Kontaxis and Chew used a Mozmill-instrumented version of Firefox to visit the top 200 news sites on Alexa, tracking the difference between a default Firefox configuration, one with Tracking Protection enabled, and one with AdBlock plus enabled.

The results recorded 4006 cookies with the default configuration, 2398 cookies with AdBlock Plus, and 1300 cookies with Tracking Protection. The statistics collected show that 50% of these top news sites include eleven or more trackers—although one (unnamed) site included 150. Perhaps more importantly, the feature also blocks requests for other resource types. The paper says that 79% of the requested elements were JavaScript, for example, and 14% were images.

The cumulative effect of blocking all of these blacklisted requests is perhaps the most startling result of the research. The team found that the median time needed to load a page went down by 44% when Tracking Protection was enabled, and the median amount of total data transferred was reduced by 39%.

Those numbers will no doubt sound appealing to many users—especially those who pay for bandwidth on a per-megabyte basis. Interestingly enough, the paper concludes with a look at user behavior. In addition to the aforementioned laboratory tests, the team also used Firefox's Telemetry framework to measure real-world usage by Firefox Nightly users between December 25, 2014 and January 7, 2015.

Just 0.5% of Firefox Nightly users enabled Tracking Protection during the study period. The numbers might be higher today, particularly in light of the speed improvements reported, but significant gains may only be achievable if the browser maker does more to make the feature easy to enable. As the paper's conclusion notes:

Finally, browser makers bear tremendous responsibility in mediating conflicts between privacy interests of users and the advertising and publishing industries. Tracking Protection for Firefox is off by default and hidden in advanced settings. We call upon Mozilla, Microsoft, and other browser makers to make tracking protection universally available and easy to use. Only then will the balance of power shift towards interests of the people instead of industry.

Since neither Kontaxis nor Chew are employed by Mozilla at present, it is only speculation to suggest that future versions of Firefox might ship with Tracking Protection switched on—although seeing it moved from an about:config option to a checkbox in Firefox's "Privacy" settings tab does not seem out of the question.

In the meantime, users of Firefox 35 and later who have not enabled Tracking Protection will probably be pleased to learn its performance characteristics. Among other details, the paper notes that Tracking Protection seems to result in far less page-breaking incidents (that is, situations where blocking a suspected tracker has the side effect of making the site unusable) than using Privacy Badger. Similarly, it points to research indicating that AdBlock Plus imposes CPU overhead that many users find unacceptable.

Perhaps the most significant distinction between AdBlock Plus, Privacy Badger, and Tracking Protection, though, is the fact that Tracking Protection is a built-in feature not a third-party add-on. In her blog announcement about the paper, Chew challenged Mozilla's leadership to "recognize that current advertising practices that enable 'free' content are in direct conflict with security, privacy, stability, and performance concerns -- and that Firefox is first and foremost a user-agent, not an industry-agent."

Should Mozilla accept that challenge, the online advertising industry will no doubt look for new methods to work its way into the browsing experience. But a 40% improvement over the speeds and data costs of the current state of affairs is hard to ignore—even without user privacy at stake.

Index entries for this article
SecurityPrivacy
SecurityWeb browsers


to post comments

Speed and bandwidth improvements with Firefox Tracking Protection

Posted May 29, 2015 7:05 UTC (Fri) by pabs (subscriber, #43278) [Link] (1 responses)

The concept of a user-centric browser is long dead, the web is built on browsers catering to the interests of web designers, web developers, advertisers and other interests.

Tracking Protection helps high-value sites

Posted May 29, 2015 19:27 UTC (Fri) by dmarti (subscriber, #11625) [Link]

Tracking protection is a win for high-value ad-supported sites. The subject of sites recommending tracking protection to users has come up on several lists, and I ended up writing this:

Your site can inform, nudge, or reward each user to turn on or install a tracking protection tool that works for his or her own browser.... Tracking protection discourages the forms of advertising that have negative externalities, and helps shift ad budgets to ads that have positive externalities.

Advertising in general has the power to support cultural goods. If you like William Gibson stories, thank an Omni magazine advertiser. But web advertising has, so far, been terrible at this. IMHO ad-supported content has a chance of working on the web, but only after we get enough of the user base out of the pool of commodity eyeballs.

Here's a quick tracking protection test that you can take to make sure you're protected (AdBlock Plus users are not, by default.

Speed and bandwidth improvements with Firefox Tracking Protection

Posted May 29, 2015 9:32 UTC (Fri) by andrewsh (subscriber, #71043) [Link] (1 responses)

While I like the benefits this new feature provides, it breaks SSO and some features on many websites, so I have to disable it quite often.

Speed and bandwidth improvements with Firefox Tracking Protection

Posted May 29, 2015 17:00 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

RequestPolicy lets you poke holes to allow things. It can be a little tedious, but it seems I don't go to enough sites for it to really matter that much. It isn't an easy tool to use though to get what you need. Takes a lot of intuition to see that "<garble>.cloudflare.com", "cdn.<mainsite>", "static.<mainsite>" and the like are the keys to getting things to be acceptable in the midst of all the crap (and there is a *lot* of it).

Speed and bandwidth improvements with Firefox Tracking Protection

Posted May 29, 2015 9:40 UTC (Fri) by Aissen (subscriber, #59976) [Link] (8 responses)

Regarding DNT vs tracking protection, it seems the ad network have what they deserved. We tried the "gentle" way by asking them to respect a user setting; they refused. Now they'll just have to live with the user blocking tracking by default.

Regarding ABP, it seems quite unfair to use it for this research: it includes a list of "acceptable ads", which could probably be the source of the additional recorded cookies. I won't go into the fairness of how this list is built.

Last but not least, if you're still using ABP, you should be moving to uBlock Origin, a much more efficient alternative. It uses less memory, and less CPU; see this research on Chrome for instance: https://github.com/gorhill/uBlock/wiki/uBlock-vs.-ABP:-ef... . I've moved all my devices to use uBlock Origin (works in Firefox for Android too).

Speed and bandwidth improvements with Firefox Tracking Protection

Posted May 29, 2015 17:02 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (4 responses)

So I use ABE (fork of ABP without the payment escape hatch) with RequestPolicy. I tried uBlock Origin, but it seemed more of a hands-off tool than RP. Did I miss something or was RP basically making uBlock useless while both were installed?

Speed and bandwidth improvements with Firefox Tracking Protection

Posted May 29, 2015 19:58 UTC (Fri) by PaXTeam (guest, #24616) [Link] (3 responses)

did you actually mean RP (long dead) or RP Continued? regardless of that, i only use uBlock (Origin, since the fork) nowadays and see no need for either AB* or RP*. you do have to RTFM at least once to understand the GUI though ;).

Speed and bandwidth improvements with Firefox Tracking Protection

Posted May 29, 2015 21:19 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

Plain old RP. I think I tried RPC at some point, but maybe it didn't work with the sync add-on I also use (which is actually useless now since I haven't moved to the new account system). I'll have to try uBlock again. I definitely didn't read its docs :) .

Speed and bandwidth improvements with Firefox Tracking Protection

Posted May 29, 2015 23:21 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

uBlock improves rapidly and half the improvements are invisible unless you pop over to read the release notes now and again. Its dynamic filtering is really quite powerful (and just expanded again), but if it wasn't for the docs you wouldn't know the controls for it were even controls at all.

Speed and bandwidth improvements with Firefox Tracking Protection

Posted May 29, 2015 23:36 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

They should do the same as NoScript and pop a tab when it updates then. I'll have to try it out when I get back from vacation. Especially since it works on Android too.

Speed and bandwidth improvements with Firefox Tracking Protection

Posted May 30, 2015 12:05 UTC (Sat) by robert_s (subscriber, #42402) [Link] (1 responses)

"Regarding DNT vs tracking protection, it seems the ad network have what they deserved. We tried the "gentle" way by asking them to respect a user setting; they refused."

Let's not forget the role Microsoft played in making DNT totally meaningless by enabling it by default in IE.

MSIE improvements

Posted Jun 1, 2015 14:51 UTC (Mon) by dmarti (subscriber, #11625) [Link]

Microsoft has finally fixed the default DNT setting in MSIE.

http://adage.com/article/digitalnext/5-excuses-dismissing...

A modern MSIE plus the EasyPrivacy TPL is a pretty fast way to get protected. This is LWN so few of you probably have the browser in front of you, but next time you're on your uncle's computer, try this:

http://blog.aloodo.org/posts/easyprivacy-for-msie/

Speed and bandwidth improvements with Firefox Tracking Protection

Posted Jun 8, 2015 17:59 UTC (Mon) by pr1268 (guest, #24648) [Link]

We tried the "gentle" way by asking them to respect a user setting; they refused.

I'm unsure there even is a "gentle" way of doing this. Consider that the ad servers having to develop and implement some server-side solution to filter out DNT requests is akin to them having to spend extra resources to deploy something which will cut off their primary source of revenue. Hmm... tough decision—NOT!

Simply ignoring the flag is the easiest solution, and it doesn't affect the ad servers' revenue stream.

And Mozilla/Firefox proudly touting this "nifty privacy feature" is shady sales tactics at best; only the totally naïve would think DNT really works (false sense of privacy).

As for Microsoft enabling DNT by default on IE, that in and of itself is also shady tactics: "We've taken this extra step to ensure your privacy online!". Hogwash.

I was skeptical about DNT from the beginning. Still am. But, I do think Tracking Protection is a much better solution. We'll see...

Speed and bandwidth improvements with Firefox Tracking Protection

Posted May 29, 2015 11:55 UTC (Fri) by joey (guest, #328) [Link] (3 responses)

I wonder how efficiently the list is transferred, if it's updated every 45 minutes. I hope they send a delta..

FWIW, since I enabled ublock, it reports that it's blocked a whopping 51% of all requests.

Meanwhile, I'm stunned that Firefox has taken to displaying advertisements in (otherwise unused) tiles in the new tab page, and only allows disabling those advertisements by disabling viewing any tiles at all. Ie, the new tiles page has been converted to an antifeature. So it sems like they have some low-lying fruit if they want to actually empower their users to block ads. Of course, Pabs is probably right -- it's looking increasingly likely that forks like GNU IceCat will be needed to get back to a browser that is a User Agent, rather than a Corporate Agent.

Speed and bandwidth improvements with Firefox Tracking Protection

Posted May 29, 2015 17:26 UTC (Fri) by andrel (guest, #5166) [Link] (1 responses)

Tracking protection and ad blocking aren't the same thing. While it is true that tracking protectors currently have a side effect of also blocking many ads, that isn't their goal, and one can imagine a world in which publishers continue their centuries old habit of selling ads without the noxious tracking. There is a strong case to be made that ads without tracking are better than ads with tracking.

Speed and bandwidth improvements with Firefox Tracking Protection

Posted Jun 4, 2015 5:25 UTC (Thu) by Mook (subscriber, #71173) [Link]

While I agree that tracking and advertising are different, these days (web) advertisers all want to track the people seeing the ads. Possibly to avoid fraudulent reporting, I guess, but that still involves tracking and it's too easy to end up remembering things that they shouldn't.

As an example, Firefox's support page on what they track:

https://support.mozilla.org/en-US/kb/how-do-tiles-work-fi...

It tracks what tiles are displayed - and since that's based on your browser history, it is linked to what you're interested in. Also includes click rate, so they get paid I guess.

Speed and bandwidth improvements with Firefox Tracking Protection

Posted Jun 5, 2015 4:42 UTC (Fri) by cpeterso (guest, #305) [Link]

You can disable the new tab's "suggested tiles" without disabling all tiles. Just open the new tab page's gear menu and uncheck "Include suggested sites":

https://support.mozilla.org/en-US/kb/how-do-tiles-work-fi...

How does this compare to Ghostery

Posted May 29, 2015 21:29 UTC (Fri) by pflugstad (subscriber, #224) [Link] (5 responses)

I use the Ghostery add-on to Firefox (https://addons.mozilla.org/En-us/firefox/addon/ghostery/) - with the Ghostrank disabled. How does this compare to that?

FWIW, I also switched to uBlock and recently updated to RP Continued. And of course, NoScript. I don't understand how people can surf the web these days without some kind of protection like these.

How does this compare to Ghostery

Posted May 30, 2015 5:33 UTC (Sat) by rbrito (guest, #66188) [Link] (3 responses)

I've seen many smart people recommending Ghostery, which means that it must, somehow, be good.

On the other hand, I read on wikipedia that they had some dubious practices. Furthermore, it seems like it is a proprietary plugin.

A (few) question(s) for those that are familiar with it:

* is it "evil" in any way?
* if I have adblock plus and ghostery installed, which acts first?
* same question as above, but now with this Firefox Tracking Protection.

If anybody knows the answers to those, I would really, really love to know.

Thanks in advance.

How does this compare to Ghostery

Posted May 31, 2015 18:50 UTC (Sun) by pflugstad (subscriber, #224) [Link] (1 responses)

Honestly, I'm kind of in the same boat. I looked into Ghostery enough to know I should not enable their "GhostRank" functionality - so it doesn't *appear* to phone home any data. So I agree it's proprietary and potentialy evil.

I'd be happy with an open alternative - maybe this Firefox Tracking Protection (FTP) is it. However, I do wonder about the Disconnect blacklist mentioned in the article - I don't see any direct link to it's blacklist - so I wonder how that's working for Firefox. The description of their product indicates that it sets up a VPN back to their servers, which seems... less than optimal to me, and ripe for abuse. The available code is GPLv3, but the trademarks are retained (typical I guess). I'm curious why Firefox couldn't use one the many other lists available.

I don't know how all these plugins interact - it would be good for some Firefox expert to clarify that. On the PC I'm currently on, I have uBlock, noscript and just turned on FTP - no Ghostery. I went to cnet.com (as the firefox demo page https://support.mozilla.org/en-US/kb/tracking-protection-... shows) and got no warning about tracking. This leads me to believe that uBlcock and/or noscript stopped that before the FTP could see it. Not a lot of info, but there ya go :-/.

Pete

How does this compare to Ghostery

Posted Jun 5, 2015 4:48 UTC (Fri) by cpeterso (guest, #305) [Link]

Disconnect's blocklist is public and GPL'd: http://services.disconnect.me/disconnect-plaintext.json

Firefox's Tracking Protection only uses a subset of it. Tracking Protection runs after add-ons like uBlock or Ghostery run (so add-ons that want to track or modify requests can still work), which explains why you see no Tracking Protection warnings on cnet.com.

How does this compare to Ghostery

Posted Jun 1, 2015 15:48 UTC (Mon) by kdave (subscriber, #44472) [Link]

I haven't observed any evil behaviour from ghostery plugin, it works well, can be configured to skip the blocking reports. The only outgoing traffic are pings for new database updates, can be disabled as well I think.

I don't know how the addon priorities are implemented. Observed behaviour matches "first installed, first in the queue". Eg. Ghostery catches the majority, and uBlock0 was still left with some work (probably because of different rule lists, no duplicates). Similar holds for Adblock (edge), only handful of additional matches.

When Disconnect was installed in pair with Ghostery, it reported 0 matches almost always. Similar with Privacy badger.

How does this compare to Ghostery

Posted Jun 4, 2015 8:13 UTC (Thu) by medhefgo (guest, #102962) [Link]

I think that there's zero point to Ghostery when you have Adblock Plus (or whatever fork you may prefer). All that's needed is adding a privacy protection filter list and it'll do what other privacy add-ons do, probably even better/faster since there's now only one add-on doing the filtering. I've been using the EasyPrivacy list since ages for this.
Additionally, you can also have a filter list to block all social media buttons completely with another filter. I haven't seen like buttons in ages :)

Regarding the comparison of the firefox protection list with adblock seems to be unfair to me as long as only a adblock filter list is used (afaik, adblock only has the ad blocking list on by default), but the article is unclear about this. It'll probably be on par if EasyPrivacy is used.

I'm glad to see this built in, however..

Posted May 30, 2015 1:31 UTC (Sat) by dw (subscriber, #12017) [Link]

..only as long as it isn't some precursor to Mozilla copying the Adblock Plus business model (paid whitelisting). I doubt that would happen, but it's not unreasonable to expect this to be a potential revenue source in the future once they've killed off all third party plugins providing similar behaviour.

the elephant in this room

Posted May 31, 2015 18:03 UTC (Sun) by tpo (subscriber, #25713) [Link] (9 responses)

Uhm, there seems to be a, wait..., salmon (?) colored (actually #ffcc99) elephant standing in this LWN room with "//pagead2.googlesyndication.com/pagead/show_ads.js" written on it.

Nobody besides me seeing it?

I am wondering whether despite all the sweet words in the original article it is actually really tracking us?
*t

the elephant in this room

Posted Jun 1, 2015 1:23 UTC (Mon) by dmarti (subscriber, #11625) [Link]

You want elephants, how about this: Targeted advertising, platform competition and privacy by Henk Kox, Bas Straathof, and Gijsbert Zwart.

This is a 44-page Economics paper that comes to the conclusion...

We find that more targeting increases competition and reduces the websites’ profits, but yet in equilibrium websites choose maximum targeting as they cannot credibly commit to low targeting.

Since a credible commitment on low targeting can't come directly from LWN (or any other individual high-quality site), LWN might as well send you the targeted ads until you do them a favor and start using tracking protection.

(What I'm working on is a way for sites to "nudge" users from more trackable to less trackable, which helps the site beat fraudulent and other low-value competitors.)

the elephant in this room

Posted Jun 1, 2015 11:11 UTC (Mon) by ballombe (subscriber, #9523) [Link] (7 responses)

> Uhm, there seems to be a, wait..., salmon (?) colored (actually #ffcc99) elephant standing in this LWN room with "//pagead2.googlesyndication.com/pagead/show_ads.js" written on it.

My /etc/host has (inter alia)

0.0.0.0 pagead2.googlesyndication.com

so no, I do not see it.

But at some point, Linux distributions are going to be complicit of user tracking by not
implementing some basic protection by default.
But how to do it while staying neutral is not obvious.

domain name blacklisting

Posted Jun 1, 2015 12:09 UTC (Mon) by tpo (subscriber, #25713) [Link] (6 responses)

Is there a way to do:

0.0.0.0 *.googlesyndication.com *.doubleclick.net
0.0.0.0 *.2o7.com

and so on? That's what I'd *really* like to do... however I don't know of any nice and elegant solution for this, short of some ugly local hack via a transparent DNS proxy.

Optimally there should be some resolver plugin that could be activated via nsswitch.conf, that does this, but AFAIK there is no such thing?
*t

domain name blacklisting

Posted Jun 1, 2015 12:27 UTC (Mon) by anselm (subscriber, #2796) [Link] (3 responses)

Dnsmasq can do this sort of thing and I personally would consider this reasonably nice and elegant. To sweeten the deal, dnsmasq can also perform other potentially useful services, like local caching of results, DNSSEC validation, and so on.

domain name blacklisting

Posted Jun 1, 2015 12:54 UTC (Mon) by tpo (subscriber, #25713) [Link] (2 responses)

Thanks for the reference -

I know dnsmask a bit and I don't like it much for its complexity: it has the kitchen sink integrated, which is also reflected in its epic manpage. The problem at hand seems to be so trivial (blacklisting domains) that I'd expect that a solution would be accordingly trivial (a simple /etc/hosts.blacklist would do)...

domain name blacklisting

Posted Jun 1, 2015 14:09 UTC (Mon) by dmarti (subscriber, #11625) [Link]

Unbound has "include" and "local-data".

https://www.unbound.net/documentation/unbound.conf.html

I recently set up an Unbound internal DNS server and it works great.

The missing piece is a script that will parse the EasyPrivacy list and generate an "include"able file containing the correct "local-data" lines.

domain name blacklisting

Posted Jun 1, 2015 15:56 UTC (Mon) by kdave (subscriber, #44472) [Link]

Dnsmasq allows to use multiple hosts files, so it's easy to separate your true /etc/hosts and 3rd party list(s). The config option is 'addn-hosts=/path', multiple allowed.

domain name blacklisting

Posted Jun 1, 2015 16:07 UTC (Mon) by kdave (subscriber, #44472) [Link]

Interesting that you mention the nsswitch approach. I've played with that some time ago and in the end it was easier to configure dnsmasq to accept multiple hosts files than to implement the getXXbyYY callbacks in a nss module. In retrospect I think that NSS is the wrong level to solve it. The resolver approach builds on top of working code (it has to parse hosts anyway), may do caching and shares the configuration.

domain name blacklisting

Posted Jun 1, 2015 19:05 UTC (Mon) by dsowen (subscriber, #81373) [Link]

For several years, I've been running both dnscache and tinydns (the djbdns package) on my network.

I configure dnscache to send all requests for *.example.com to the local tinydns instead of resolving recursively from the DNS roots. I configure tinydns to be an authority for that domain (this is only inward-facing), then leave it with no A records for it. So a query for anything in *.example.com fails immediately, and I think that even the failure gets cached.

I have a short bash script to add a domain to both dnscache and tinydns and reload each. Whenever I catch a site misbehaving, I open up the browser's dev tools, track it down, and ban it. I don't mind ads, generally; ad servers that don't misbehave don't get banned.

When visitors use my network, they comment on how fast everything loads (but I have only 5 Mbps incoming) and how clean every site looks.

:)


Copyright © 2015, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds